\documentclass{beamer}

\usepackage{graphicx}

\usetheme{Warsaw}

\title[Enforcing Request Integrity in Web Applications]{Enforcing Request Integrity in Web Applications}
\author[K. Jayaraman, G. Lewandowski, P. Talaga, S. Chapin]{Karthick Jayaraman, Grzegorz Lewandowski, Paul G. Talaga, and Steve J.
Chapin}
\institute{DBsec 2010}
\date{June 23, 2010}

\begin{document}

%-------------------------------------------------------------------------------
\begin{frame}
\titlepage
\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Request Sequence}

Web applications are developed with some task(s) in mind. The desired
functionality can be described using:

\begin{itemize}

\item use cases
\item usage scenarios
\item storyboards
\item vague ideas in developer's head
\item ...

\end{itemize}

We think about applications and their functionality as sequences of steps. In
case of web applications, these sequences naturally become sequences of HTTP
requests. The desired functionality can then be represented as
\emph{intended request sequence(s)}.

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Fundamental Weakness}

\begin{itemize}

\item Web applications' architecture gives the client a lot of control over
applications' execution, and yet

\item Web applications rarely enforce intended request sequences, often
performing only partial validation and/or relying on the client to present/hide
appropriate interface. Moreover,

\item Web applications' structure is public and constant

\end{itemize}

\begin{block}

Attackers can easily research web applications and then trick them into
processing \emph{unintended request sequences} - we call these type of attacks
\emph{request integrity attacks} (RIA)

\end{block}

\end{frame}
%-------------------------------------------------------------------------------
\begin{frame}{Exploitation}

\begin{itemize}

\item How do request integrity attacks manifest themselves?

\item What are the possible results of a request integrity attack?

\begin{itemize}

\item Workflow attack bypasses certain steps of an intended sequence

\item Cross-site request forgery injects steps into someone else's request
sequence

\end{itemize}

\end{itemize}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Workflow Attack}

A classic example of workflow attack is an attack on a shopping site checkout
sequence.

\begin{figure}
\includegraphics[scale=0.6]{img/workflow}
\end{figure}

A workflow attack is an RIA executed by the user manipulating his/her own request
sequence.

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Cross-site Request Forgery}

A malicious site can trick Alice into performing an unintended action.

\begin{figure}
\includegraphics[scale=0.5]{img/csrf}
\end{figure}

A CSRF attack is an RIA executed by a third party manipulating user's request
sequence.

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Counterexample}

Example(s) of attacks that are not request integrity attacks.

\begin{itemize}

\item An XSS attack is not an RIA. It could be used to launch an RIA but in itself
it is not one

\item A SQL injection attack is not an RIA

\end{itemize}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Defense}

How to enforce request sequence integrity?

\begin{itemize}

\item There already exist mechanisms for policing sequences of steps. The
sequences are called \emph{executions} and the techniques are known as
\emph{execution monitoring}

\item Perhaps intended request sequences can be enforced using execution
monitoring techniques?

\begin{itemize}

\item Web applications serve multiple simultaneous users - their requests
sequences will be multiplexed

\item Web browsers allow CSRF - request sequences might contain injected
requests

\item Users can open multiple pages of the same application simultaneously -
state tracking becomes harder

\end{itemize}

\end{itemize}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Defense}

\begin{figure}
\includegraphics[scale=0.6]{img/bayawak2}
\end{figure}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Anatomy of a Web Application}

\begin{itemize}

\item \emph{Request flow graph}

\item \emph{Interfaces} - receive requests and return web pages; identified by
\emph{interface names}, e.g. /mboard/viewforum.php

\item Requests are grouped into \emph{sessions}


\end{itemize}

\begin{figure}
\includegraphics[scale=0.4]{img/mboard}
\end{figure}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Behavior-preserving Diversification}

Create a session-specific RFG by appending random numbers (interface identifiers)
to interface names.

\begin{columns}

\begin{column}{0.5\textwidth}

\begin{figure}
\includegraphics[scale=0.4]{img/mboard}
\end{figure}

\end{column}

\begin{column}{0.5\textwidth}

\begin{figure}
\includegraphics[scale=0.4]{img/mboard_rnd}
\end{figure}

\end{column}

\end{columns}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Request Validation}

\begin{itemize}

\item Web page content is modified to use correct interface identifiers,
/viewforum.php becomes /viewforum.php?W=A23F1789C4327EA

\item Incoming requests are validated by checking interface identifiers -
legitimate requests created via user's interaction with the application will
carry the correct identifiers

\end{itemize}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Bayawak}

\begin{figure}

\includegraphics[scale=0.5]{img/bayawak}

\end{figure}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Implementation}

\begin{itemize}

\item Apache mod\_perl module or Java Servlet API filter module

\item http://code.google.com/p/bayawak/

\end{itemize}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Experimentation}


\begin{itemize}

\item 9 web applications: phpBB, punBB, Scarf, osCommerce, WebCalendar, Bookstore,
Classifieds, Employees, Events

\item 4 workflow attacks and 45 CSRF attacks

\item Bayawak defeated all attacks

\item Performance overhead varies, it depends on page complexity, not application
complexity
\begin{itemize}

\item best case - a complex application with simple pages: 3.5\%
\item worst case - simple application with complex pages: 94\%
\end{itemize}
\end{itemize}

\end{frame}

%-------------------------------------------------------------------------------
\begin{frame}{Questions?}

\center{\Huge{\textbf{?}}}

\end{frame}

\end{document}
